滴滴业务中台构建，到底有多牛？

点击“开发者技术前线”，选择“星标🔝”

在看|星标|留言,  真爱

作者丨小智  嘉宾丨何修峰 来自：infoQ

滴滴是一家以出行为核心、辐射单车、代驾、车服、金融、国际化等领域的科技公司，在各条业务线飞速发展的过程中会存在着很多相同或者类似的业务需求，如何通过技术的手段抽象、沉淀这些业务为通用、稳定基础能力，让各业务线专注于其个性化的部分，快速的推出适合市场的新产品，是业务中台核心价值的体现。在近期召开的 QCon 上海 2019 大会现场，InfoQ 记者采访了滴滴出行高级技术专家何修峰，他向记者分享了滴滴的业务中台构建实践。

1 滴滴业务中台发展历程

滴滴做中台已经有好几年的历史。早在 2015 年，滴滴就开始组建中台，2016 年的时候方向调整做了出行中台，目前滴滴很多出行业务都是基于这个中台。滴滴的很多业务场景，都是配置出来的，在出行中台里面进行孵化，孵化了之后，通用能力像支付、定单、计价、passport 等，不但能支持出行，也能支持别的业务，于是出行中台在今年年初演进成了公司级的业务中台，把原有中台中更加通用的部分带过来了。

目前整个滴滴业务中台团队研发有一百多人，算上产品经理团队规模更大。目前滴滴的大部分业务场景都在使用业务中台，已经构建了订单中心、计价中心、支付中心、passport、用户中心、触达平台六大能力。

搭建业务中台，不应完全从技术的层面来看，因为业务中台最终要看到的是仍旧如何快速支撑业务。技术只是实现业务的手段，滴滴本身也有技术中台，用来提供一些基础的设施，像云基础设施、MQ、NOSQL 存储、监控平台等，业务中台背后有提供大量技术支撑的技术中台。

除了技术中台以外，滴滴还有规模庞大的大数据团队在做数据中台，业务中台是依托于技术、数据中台，更贴近于业务，主要是对业务负责。最终业务中台能做到对整个业务进行抽象，把通用的部分沉淀下来。从整体来讲，我们支持业务的发展，让业务能跑得更快。

举个例子，各个业务模块过去没有支付系统，从头开发一套支付是很麻烦的，现在有了业务中台可以一键接入支付，至于下单后，微信支付宝怎么调用，怎么支付，失败后怎么处理，就不需要业务方再去操心了，依赖业务中台的统一接口就可以搞定，在整个业务的支持上来讲，肯定是让它更快了。

滴滴在 2015 年的时候就开始尝试搭建中台，有了一些成果，到了 2016 年，公司调整思路，从比较务实的角度出发，提出基于最大的业务线——出行业务线去孵化滴滴出行中台的思路。当时提出了一个目标，滴滴的业务肯定是配置的，最合适的十几分钟就能配置出来。

经过几年的发展，慢慢进化到今天这个样子。从 0 到 1 的过程中，最主要就是务实，基于解决问题，从业务出发，再基于当前的最大业务线做孵化，逐步迭代、逐步抽象，小步跑快，最终达到一个比较理想的状态。

2015 年的时候，中台的概念还不是那么火，业界都处于摸着石头过河的状态。同一件事情，会出现不同的解决方案。小步快跑、快速试错的方式比较容易成功，另一种可能最开始的规划比较多，受外界影响的变化也比较多，最终可能导致做出来的东西跟实际情况不匹配，或者需要经常改影响了实际效果。滴滴也有类似的尝试，结果并不是很成功，所以就换了另一条思路，最终在 2016 年开始取得了一些成果。

2 业务中台要紧贴业务

滴滴出行业务会有高峰期的概念，工作日的早晚高峰、节假日的高峰期，中台对于业务的支撑也会加大支持力度。业务中台是整个业务中非常重要的一环，针对高峰期，中台部门需要在处理方案上做功夫，至于这个模块中台不好处理能否放在业务部门，或者业务部门不好处理能否放在中台，都是可以商量的。对于最核心的业务，比如滴滴的出行业务，在技术上的投入、资源上的倾斜力度都会更大。

业务中台是为业务服务的，跟业务线要走得很近，滴滴今年在内部提出“向前一步”，每个技术团队都会向前一步，了解你前面所支撑的业务到底是什么样的，这样整个前后信息是打通的，从一个统一的认知上去理解问题、沟通问题，最终就更加容易达成一致。

业界一些中台部门存在的业务接入遇到阻碍的问题，在滴滴这很少遇到，因为滴滴的业务中台直接是从最大的业务中孵化出来的。订单中心、计价中心、支付中心、passport、用户中心、触达平台等都是配置孵化而来，对于目前不需要中台的业务线，中台部门也不会去强制接入，内部更多是通过沟通机制划定边界。

中台团队需要下到各个业务线去沟通，考虑对方的需求如何通过我们的抽样能力、复用能力，以最终达到提高人效的结果。背后会有一些资源上的倾斜，需要沟通、对齐，对于滴滴而言整体最优是最合理的。达成整体最优就需要共同协商、解决，可能有些需求暂时排不上期，就会让业务线自己先做，中台部门永远不可能比业务线人多，同样也不可能像业务线那样对于业务的变化那么敏感，在这个过程里，需要中台部门与业务线之间拉通信息以解决问题。

3 业务中台跟技术人员的区别

滴滴业务中台部门的成员大部分是内部转化，最开始的出行中台孵化出来了一些工具和基础能力，带来了一些业务中台部门的早期成员。中台部门其实是有些延续性的，也会招聘一些新的人，但只要有老人这些文化、种子存在，新人进来以后就会快速融入，融入之后带来新的思想、新的碰撞，可能会产生新的思路、新的文化。

业务中台部门成员跟纯粹的底层开发之间肯定存在一些差异，相对而言前者的技术工作可能更加容易，跟真正的业务开发人员相比，对业务的了解也会存在一些差距。所以，滴滴提出“向前一步”的做法，也是希望中台人员能跟业务开发人员拉齐，久而久之就会有业务上的感觉，也可能对未来业务发展产生自己的想法，同时基于对内部技术、后台的理解，做出一些技术上的创新，从而支撑整个的业务层未来的创新。

理论上来说，业务部门的开发人员可以做任意开发需求，但这背后存在一个性价比的问题。比如说登录功能，任何一家小公司、小团队都可以做，但是不是能做到体验一致？比如说滴滴一家公司有好几个 App，如果每个 App 的体验做得都不一样，用户会怎么想？

所以对业务中台部门而言，以一个统一的接口去做系统的优化，沉淀下那些通用的能力，这是性价比最高的方案。此外，中台部门在技术上也会做得更深入一点，考虑更加全局化一点，不会随意造轮子。

4 中台是微服务的集散地吗？

中台是微服务的集散地这个观点我不认同。所谓集散地，代表的是一种杂乱无序的状态，是一大堆东西硬塞进去的混乱的地方，但中台背后一定是有一套机制、一群人来保障、有序的状态。

中台部门首先是有序的、有规划的，其次是解决一些业务上的问题，并且在这些业务问题之间，中台团队试图去把它打通，找出共性。再者，中台是有自己的门槛的，不是随便写个微服务或者其他的组件就可以放到中台里。中台部门希望技术团队去贡献一些基础能力，但贡献出来的基础能力最终是否能融入到中台里，最终仍旧需要通过一定的机制去做相应的评估。因为一旦进入中台，就有责任对它去做扩展、推广、运营，保证其生命周期，让其长久地活下去。

杂乱无序的集散地，汇集的肯定不止各种各样的微服务模块，还有其他杂七杂八的组件，缺乏强有力的管理，它的生命力是不会长久的。

但微服务对于构建中台而言是一个很好的技术手段。现阶段，构建一个大型的互联网系统，普遍为业界接受的基本上就是微服务加上 DDD（领域驱动设计）的架构设计模式。互联网迭代速度快，传统的单体架构模式无法适应，而微服务因为比较简单灵活、独立扩展、发挥，对技术栈没有特别要求，底层存储也不要求跑在同一个数据库上，是现阶段互联网架构设计的一种比较好的解决方案。中台团队服务的是大型互联网企业的业务，也需要灵活的变化，跟微服务的理念是相吻合的。

当然微服务也存在一些问题，比如网络上的不可靠性等等。任何一种技术，如果缺乏规范化的管理，最终都会陷入杂乱无序的状态，因此也催生了微服务的治理平台。滴滴是一个比较新的公司，技术上有后发优势，技术债比较小一点，目前在中台层面使用的微服务治理做得比较令人满意。

5 滴滴中台未来发展方向

滴滴业务中台的发展方向仍在探索中，在此之前我们已经构建了订单中心、计价中心、支付中心、passport、用户中心、触达平台六大能力。现在首先是要满足对各个业务线的支撑，做到又稳定又快又高效。

第二阶段，我们希望业务之间能够打通，联结起来，做到赋能。比如 A 业务做了一个新功能，B 业务可以直接拿过来，通过业务中台赋能，产生更多新的玩法。

第三阶段，做到业务之间的协同与创新。通过业务中台作为一个统一的出口，对一些新业务做管控，让它保持在正确的轨道上发展。

END

前线推出学习交流群，加群一定要备注：研究/工作方向+地点+学校/公司+昵称（如大数据+上海+上交+可可），根据格式备注，可更快被通过且邀请进群，领取一份专属学习礼包

扫码加我微信进群，内推和技术交流，大佬们零距离

后台回复 “666” 即可领取程序员大礼包。

历史阅读

「在看」大家一起看